fix(plugin-list): ObjectGallery waits for the object definition instead of querying twice (objectui#7903) - #7919

Fixes #7903

ObjectGallery sat outside the set objectui#6482 converged on the shared
settled-schema gate — ObjectKanban, ObjectView, ObjectCalendar and
ObjectTree were named there, ObjectGantt was ask 2 of objectui#7225, and
ObjectTimeline was objectui#7895 — and nothing marked it a deliberate
exclusion. It held the object definition in a local useState fed by its own
metadata effect and listed that definition in the record-fetch effect's
dependency array.

The card said "shape reading, NOT measured" — so it was measured first

The filing seat spotted the shape while working objectui#7895 and did not
measure it. Instrumented renderer (a React.Profiler commit counter reading the
rendered card grid), writes counted per single mount, getObjectSchema held
at a fixed delay, grid 0/1/2/3/4/5/6/7/8/9/10/15/25/50/100 ms, with
ObjectCalendar as a positive control in the same vitest run.

Every reading held at every one of the fifteen holds, not one band of them.

1. Call count and expand set. The decisive reading objectui#7895 named
   reproduces exactly: [null, ['owner']]. The first call goes out with no
   expansion, so the first paint is raw foreign-key ids. The issue order was
   schema:issued, find(unexpanded), schema:settled, find(expanded) at every
   hold including +0 ms; after the gate it is
   schema:issued, schema:settled, find(expanded).
2. Paints and late writes. Before: two distinct painted states and 3 late
   writes into the card grid after the first paint, at every hold. After: one
   state, 0 late writes.
3. First paint flat or tracking. ⭐ Before, first paint was flat at 3-7 ms
   across a 0 to 100 ms sweep — it painted before the metadata, which is the
   defect. After, it tracks: 9 ms at +3, 15 ms at +10, 35 ms at +25, 106 ms
   at +100. The control tracked the hold in both directions (33-69 ms at low
   holds, 77 ms at +50, 161 ms at +100), so the instrument reads a live gate
   rather than a flat machine.

The late-write lower edge sat where objectui#7895 measured it (nothing at +0
to +2, stable from +3 up) once the readiness predicate is what counts them;
counted from the first paint instead, the 3 late writes are present at every
hold. The grid was refined rather than repeated: no hold measured nothing.

⚠️ This component's visible cost is a TWO-step paint, not the three-step one

Measured here rather than inherited from the matching shape — objectui#6482's own
per-component standard. ObjectCalendar (objectui#6453) and ObjectTimeline
(objectui#7895) both make loading an unconditional early return, so the
re-run's setLoading(true) drops them back to their placeholder between the two
paints. Here the early return is loading && !items.length: once the first (raw)
rows are in state the skeleton cannot come back. Measured skelAfter=false at
every hold — the user saw raw foreign-key ids replaced in place by the
expanded rows.

The two deliberate departures, each judged for this component

objectui#7895 made two departures from ObjectCalendar / ObjectGantt. Both
apply here, and each for a stronger reason than on the timeline:

1. The metadata read is NOT disabled on the authored-items path. dataSource
   is passed unconditionally, not hasInlineData ? undefined : dataSource. Yes,
   ObjectGallery has an authored path — three of them (props.data,
   schema.data, bind) — and it reads the definition on every one:
   buildEnrichedField reads objectDef.fields for each visible field's type,
   options, currency, precision and reference target, and
   getRecordDisplayName(objectDef, item) resolves each card's title under
   ADR-0079. Disabling the read would strip cell semantics and card titles off
   exactly the paths that issue no query.
2. The gate key is schema.objectName, not resolveRecordSourceObjectName.
   No, ObjectGallery does not resolve a data block. That reader's second rung
   is a resolved provider config (dataConfig.provider === 'object'), and
   ObjectGallerySchema['data'] is typed Record<string, unknown>[] — a bare
   inline record array, not a provider config. The component calls
   getDataConfig nowhere, so the ladder would degenerate to schema.objectName
   with extra spelling, while dataSource.find(schema.objectName, …) is the name
   the query itself uses.

A third decision, this component's own, named rather than smuggled. loading
starts false here and was only ever flipped inside the fetch, so a bare
return at the gate would show "No items to display" for the whole metadata read
— a false empty state where the pre-gate component showed the loading
placeholder. The two siblings get this from their initial state
(ObjectCalendar starts loading at true; ObjectTimeline computes it in a
lazy initializer). Rather than restructure this component's initial state — which
would change what schema.data: [] and props.data: [] render — the guarantee
is stated in the one branch that knows a query is coming, and pinned by its own
case. This is not a fourth gate shape: the gate is the converged
useSettledSchema + if (!ready) return in the querying branch.

Ablation

The fix was committed first, then packages/plugin-list/src/ObjectGallery.tsx
was reverted with a pinned commit sha (6a9ee323e, the merge-base — never a
moving remote-tracking name).

• Mutation confirmed on disk, not by an exit code: git hash-object read
  49ee0b6f821ed6d51122b40c850d43661f33bf5e, equal to the pinned commit's blob
  and different from HEAD's 9a0ddc5419733eb3de938ef20645d217c46e04bc. Anchor
  counts under mutation: useSettledSchema 0, objectDefReady 0, setObjectDef
  2.
• Restore proven by an empty git diff HEAD plus a disk blob equal to
  HEAD:packages/plugin-list/src/ObjectGallery.tsx
  (9a0ddc5419733eb3de938ef20645d217c46e04bc), with git status --porcelain
  empty and the anchors back at 3/3/0. The restore ran from a trap … EXIT INT TERM using an absolute path resolved from git rev-parse --show-toplevel.
• ⭐ No rebuild leg applies, and this is stated rather than omitted. The
  instrument imports ../ObjectGallery by relative path, and the root
  vitest.config.mts alias table points every @object-ui/* specifier at that
  package's src/ (@object-ui/react → packages/react/src), so no dist is
  on the resolution path. The ablation is itself the proof: the source mutation
  turned the pins red with no build step anywhere, which a dist-resolved
  suite could not have done.

Prediction was recorded before the run: 5 red, 2 green. Observed: 5 red, 2
green — the same five.

Second-order payoff: there is no sibling ladder fixture to re-measure

Reported whichever way it came out. The colorFieldLadder-7243 fixture set has
exactly three members — ObjectCalendar, ObjectGantt, ObjectTimeline — the
three renderers that consume createFieldColorResolver from core.
packages/plugin-list/ contains no member of it (grep for
colorFieldLadder / createFieldColorResolver / 7243 across the package
returns nothing), because ObjectGallery renders option colours through
getCellRenderer instead. Nor does any of the three existing gallery tests carry
the pre-#7521 harness shape: the module-level shared-capture harness exists in
this package only in ListView.* files, none of which mount ObjectGallery. So
there is nothing here that would still redden under the pre-#7521 harness shape,
and no guard was deleted or relaxed — a guard's value does not depend on
there being a live trigger today.

Scope

Fetch sequencing only, as ruled. Untouched: objectui#7390's unbounded
fetch / ObjectGallerySchema paging surface on this same file (ruled not
dispatchable), objectui#7429's $expand / FLS question, and
ObjectTimeline / ObjectGantt / ObjectCalendar.

Verification

All on the pushed commit b1b3c4b20, with git diff HEAD empty.

• vitest run packages/plugin-list/ — 68 files, 860 tests passed.
• vitest run …/ObjectGallery.fetchGate-7903.test.tsx — 7 passed.
• pnpm --filter @object-ui/plugin-list type-check — exit 0, running
  tsc --noEmit && tsc -p tsconfig.test.json. Proven non-vacuous:
  tsc -p tsconfig.test.json --listFiles names the new pin file, the component,
  and the built useSettledSchema declaration.
• Dependency closure built first
  (pnpm --workspace-concurrency=2 --filter '@object-ui/plugin-list^...' build).
• eslint --no-inline-config on both changed files: 0 errors. The single
  react-hooks/set-state-in-effect warning is pre-existing, at the untouched
  setFetchedData(props.data) line.
• node scripts/check-changeset-presence.mjs — verdict quoted verbatim:
  ✅ 2 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s): .changeset/7903-gallery-settled-schema-gate.md.
  The patch bump follows the checker's own ceiling
  (Scored minor at most, never major).
• node scripts/check-changeset-no-major.mjs — ✅ No changeset declares a major bump.
• node scripts/check-governed-queue-guard.mjs --test … — verdict verbatim:
  ✅ NOT GOVERNED — 3 path(s) checked against 5 governed surface(s); none matched.
An ordinary pull request: the normal review and merge-queue route applies.
• Gate family re-derived from the changed paths and re-run after the final
  commit, all exit 0: check:control-bytes, check:self-import,
  check:phantom-deps, check:esm-specifiers, check:vi-mock-specifiers,
  check:vi-mock-inherit, check:unreferenced-sources,
  check:element-data-source-declaration. Their scanned populations moved with
  the commit (control-bytes 6396 → 6398 tracked text files; the vi-mock gates
  4331 → 4332 source files), so the new files are inside what they graded.

Declared narrowing: the repo-wide pnpm lint scan is left to CI, which runs
the farm exactly once regardless. Local linting was scoped to the two changed
files.

🤖 Generated with Claude Code

Generated by Claude Code

Generated by Claude Code